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Abstract 


This document updates the guidelines and recommendations, as well as 
the IANA registration processes, for the definition of Uniform 
Resource Identifier (URI) schemes. It obsoletes RFC 4395. 


Status of This Memo 
This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7595. 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The Uniform Resource Identifier (URI) protocol element and generic 
syntax is defined by [RFC3986]. Each URI begins with a scheme name, 
as defined by Section 3.1 of RFC 3986, that refers to a specification 
for identifiers within that scheme. The URI syntax provides a 
federated and extensible naming system, where each scheme’s 
specification can further restrict the syntax and define the 
semantics of identifiers using that scheme. 


This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] 
and [RFC2718]. Recent documents have used the term "URI" for all 
resource identifiers, avoiding the term "URL" and reserving the term 
"URN" explicitly for those URIs using the "urn" scheme name 
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[RFC2141]. URN "namespaces" [RFC3406] are specific to the "urn" 
scheme and are not covered explicitly by this specification. 


This document provides updated guidelines for the definition of new 
schemes, for consideration by those who are defining, registering, or 
evaluating those definitions. In addition, this document provides an 
updated process and mechanism for registering schemes within the IANA 
URI Schemes registry. There is a single namespace for registered 
schemes. The intent of the registry is to: 


Oo provide a central point of discovery for established URI scheme 
names and easy location of defining documents for schemes; 


o discourage multiple separate uses of the same scheme name; 


o help those proposing new scheme names to discern established 
trends and conventions and to avoid names that might be confused 
with existing ones; and 


o encourage registration by setting a low barrier for registration. 
1.1. URIs and IRIs 


As originally defined, URIs only allowed a limited repertoire of 
characters chosen from US-ASCII. An Internationalized Resource 
Identifier (IRI), as defined by [RFC3987], extends the URI syntax to 
allow characters from a much greater repertoire to accommodate 
resource identifiers from the world’s languages. RFC 3987 [RFC3987] 
also defined a mapping between URIs and IRIs. IRIs use the same 
scheme names as URIs. Thus, there is no separate independent 
registry or registration process for IRI schemes: the URI Schemes 
registry is used for both URIs and IRIs. Those who wish to describe 
resource identifiers that are useful as IRIs should define the 
corresponding URI syntax and note that the IRI usage follows the 
rules and transformations defined in [RFC3987]. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


This document distinguishes between a "scheme specification", which 
is a document defining the syntax and semantics of a scheme, and a 
"scheme registration request", which is the completed template 
submitted to IANA. The term "scheme definition" refers generically 
to the syntax and semantics of a scheme and is typically documented 
in a scheme specification. 
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3. Requirements for Permanent Scheme Definitions 


This section gives considerations for new schemes. Meeting these 
guidelines is REQUIRED for /’permanent’ scheme registration. 
‘Permanent’ status is appropriate for, but not limited to, use in 


standards. For URI schemes defined or normatively referenced by IETF 
Standards Track documents, /’/permanent’ registration status is 
REQUIRED. 


[RFC3986] defines the overall syntax for URIs as: 


URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 


A scheme definition cannot override the overall syntax for URIs. For 
example, this means that fragment identifiers cannot be reused 
outside the generic syntax restrictions and that fragment identifiers 
are not scheme specific. A scheme definition must specify the scheme 
name and the syntax of the scheme-specific part, which is clarified 
as follows: 


URI = scheme ":" scheme-specific-part [ "#" fragment ] 
scheme-specific-part = hier-part [ "?" query ] 
3.1. Demonstrable, New, Long-Lived Utility 


In general, the use and deployment of new schemes in the Internet 
infrastructure can be costly; some parts of URI processing are often 
scheme dependent. Introducing a new scheme might require additional 
software not only for client software and user agents but also in 
additional parts of the network infrastructure (gateways, proxies, 
caches) [W3CWebArch]. Since scheme names share a single, global 
namespace, it is desirable to avoid contention over use of short, 
mnemonic scheme names. New schemes ought to have utility to the 
Internet community beyond that available with already registered 
schemes. The scheme specification SHOULD discuss the utility of the 
scheme being registered. 


3.2. Syntactic Compatibility 


[RFC3986] defines the generic syntax for all URI schemes, along with 
the syntax of common URI components that are used by many URI schemes 
to define hierarchical identifiers. [RFC3987] extended this generic 
syntax to cover IRIs. All scheme specifications MUST define their 

own URI <scheme-specific-part> syntax. Care must be taken to ensure 
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that all strings matching their scheme-specific syntax will also 
match the <absolute-URI> grammar described in [RFC3986]. 


New schemes SHOULD reuse the common URI components of [RFC3986] for 
the definition of hierarchical naming schemes. If there is a strong 
reason for a scheme not to use the hierarchical syntax, then the new 
scheme definition SHOULD follow the syntax of similar previously 
registered schemes. 


Schemes that are not intended for use with relative URIs SHOULD avoid 
use of the forward slash "/" character in order to avoid unintended 
processing, such as resolution of "." and ".." (dot segments). 


Schemes SHOULD avoid improper use of "//". The use of double slashes 
in the first part of a URI is not a stylistic indicator that what 
follows is a URI: double slashes are intended for use ONLY when the 
syntax of the <scheme-specific-—part> contains a hierarchical 
structure. In URIs from such schemes, the use of double slashes 
indicates that what follows is the top hierarchical element for a 
naming authority (Section 3.2 of RFC 3986 has more details). Schemes 
that do not contain a conformant hierarchical structure in their 
<scheme-specific-part> SHOULD NOT use double slashes following the 
"<scheme>:" string. 


New schemes SHOULD clearly define the role of reserved characters 
(see Section 2.2 of [RFC3986]) in URIs of the scheme being defined. 
The syntax of the new scheme should be clear about which of the 
"reserved" set of characters are used as delimiters within the URIs 
of the new scheme, and when those characters must be escaped, versus 
when they can be used without escaping. 


3.3. Well Defined 


While URIs might or might not be defined as locators in practice, a 
scheme definition itself MUST be clear as to how it is expected to 
function. Schemes that are not intended to be used as locators 
SHOULD describe how the resource identified can be determined or 
accessed by software that obtains a URI of that scheme. 


For schemes that function as locators, it is important that the 
mechanism of resource location be clearly defined. This might mean 
different things depending on the nature of the scheme. 


In many cases, new schemes are defined as ways to translate between 
other namespaces or protocols and the general framework of URIs. For 
example, the "ftp" scheme translates into the FTP protocol while the 
"mid" scheme translates into a Message-ID identifier of an email 
message. For such schemes, the description of the mapping SHOULD be 
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complete and in sufficient detail so that the mapping in both 
directions is clear: how to map from a URI into an identifier or set 
of protocol actions or name in the target namespace, and how legal 
values in the base namespace, or legal protocol interactions, are 
represented in a valid URI. See Section 3.6 for guidelines for 
encoding strings or sequences of bytes within valid character 
sequences in a URI. If not all legal values or protocol interactions 
of the base standard can be represented using the scheme, the 
definition SHOULD be clear about which subset is allowed and why. 


3.4. Definition of Operations 


As part of the definition of how a URI identifies a resource, a 
scheme definition SHOULD define the applicable set of operations that 
can be performed on a resource using the URI as its identifier. A 
model for this is HTTP methods; an HTTP resource can be operated on 
by GET, POST, PUT, and a number of other methods available through 
the HTTP protocol. The scheme definition SHOULD describe all well- 
defined operations on the resource identifier and what they are 
supposed to do. 


Some schemes don’t fit into the "information access" paradigm of 
URIs. For example, "telnet" provides location information for 
initiating a bidirectional data stream to a remote host; the only 
operation defined is to initiate the connection. In any case, the 
operations appropriate for a scheme SHOULD be documented. 


Note: It is perfectly valid to say that "no operation apart from GET 
is defined for this URI." It is also valid to say that "there's only 
one operation defined for this URI, and it’s not very GET-like." The 
important point is that what is defined on this scheme is described. 


Scheme definitions SHOULD define a "default" operation for when a URI 
is invoked (or "dereferenced") by an application. For example, a 
common "default" operation today is to launch an application 
associated with the scheme name and let it use the other URI 
components as inputs to do something. The default invocation, or 
dereferencing, of a URI SHOULD be "safe" in the sense described by 
Section 3.4 of [W3CWebArch]; i.e., performing such an invocation 
should not incur any additional obligations by doing so. 


3.5. Context of Use 


In general, URIS are used within a broad range of protocols and 
applications. For example, URIs are commonly used within hypertext 
documents as references to other resources. In some cases, a scheme 
is intended for use within a different, specific set of protocols or 
applications. If so, the scheme definition SHOULD describe the 
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intended use and include references to documentation that define the 
applications and/or protocols cited. This does not obviate the need 
for documentation on applications and/or protocols to discuss URI 
schemes relevant to them. 


3.6. Internationalization and Character Encoding 


When describing schemes in which (some of) the elements of the URI 
are actually representations of human-readable text, care should be 
taken not to introduce unnecessary variety in the ways in which 
characters are encoded into octets and then into URI characters; see 
[RFC3987] and Section 2.5 (especially the last paragraph) of 
[RFC3986] for guidelines. If URIs of a scheme contain any text 
fields, the scheme definition MUST describe the ways in which 
characters are encoded and any compatibility issues with IRIs of the 
scheme. 


The scheme specification SHOULD be as restrictive as possible 
regarding what characters are allowed in the URI because some 
characters can create several different security issues (see, for 
example, [RFC4690]). 


Percent-encoded character sequences are automatically included by 
definition for characters given in IRI productions. This means that 
if you want to restrict the URI percent-encoded forms in some way, 
you must restrict the Unicode forms that would lead to them. In most 
cases, it is advisable to define the actual characters allowed in an 
IRI production in order to allow the /’pct-encoded’ definition from 
Section 2.1 of [RFC3986] at the same places and to add prose that 
limits percent escapes to those that can be created by converting 
valid UTF-8 character sequences to percent-—encoding. 


3.7. Clear Security and Privacy Considerations 


Definitions of schemes MUST be accompanied by a clear analysis of the 
security and privacy implications for systems that use the scheme; 
this follows the practice of Security Consideration sections within 
IANA registrations [RFC5226]. 


In particular, Section 7 of RFC 3986 [RFC3986] describes general 
security considerations for URIs while [RFC3987] gives those for 
IRIs. The definition of an individual scheme should note which of 
these apply to the specified scheme, in addition to any more scheme- 
specific concerns. For example, if the scheme-specific part is 
privacy sensitive, then that should be documented. 
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3.8. Scheme Name Considerations 


Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this 
syntax remains the same for IRIs. New scheme registrations MUST 
follow this syntax, which only allows a limited repertoire of 
characters (taken from US-ASCII). Although the syntax for the scheme 
name in URIs is case insensitive, the scheme name itself MUST be 
registered using lowercase letters. 


Scheme names SHOULD be short but also sufficiently descriptive and 
distinguished to avoid problems. 


Schemes SHOULD NOT use names or other symbols that might cause 
problems with rights to use the name in IETF specifications and 
Internet protocols. For example, be careful with trademark and 
service mark names. (See Section 3.4 of [RFC5378]). 


Schemes SHOULD NOT use names that are either very general purpose or 
associated in the community with some other application or protocol. 
Schemes also SHOULD NOT use names that are overly general or 
grandiose in scope (e.g., that allude to their "universal" or 
"standard" nature). 


A scheme name is not a "protocol." However, like a service name as 
defined in Section 5 of [RFC6335], it often identifies a particular 
protocol or application. If a scheme name has a one-to-one 
correspondence with a service name, then the names SHOULD be the 
same. 


Some organizations desire their own namespace for URI scheme names 
for private use (see Section 6). In doing so, it is important to 
prevent collisions and to make it possible to identify the owner of a 
private-use scheme. To accomplish these two goals, such 
organizations SHOULD use a prefix based on their domain name, 
expressed in reverse order. For example, a URI scheme name of 
com.example.mything might be used by the organization that owns the 
example.com domain name. Care must be taken, however, if the 
organization later loses the domain name embedded in their scheme 
names since domain name registrations are not permanent. To 
associate the private-use scheme name with the original organization, 
the private-use scheme can be registered using the registration 
procedure in Section 7. 


Furthermore, to prevent collisions with private-use scheme names, new 


scheme names registered MUST NOT contain a "." unless actually 
constructed from a reversed domain name. 
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3.9. Interoperability Considerations 


If the person or group registering the scheme is aware of any details 
regarding the scheme that might impact interoperability, identify 
them, for example, proprietary or uncommon encoding methods, or 
incompatibility with types or versions of any underlying protocol. 


4. Guidelines for Provisional URI Scheme Registration 


‘Provisional’ registration can be used for schemes that are not part 
of any standard but that are intended for use (or observed to be in 
use) that is not limited to a private environment within a single 
organization. ‘’Provisional’ registration can also be used as an 
intermediate step on the way to ’permanent’ registration, e.g., 
before the scheme specification is finalized as a standard. 


For a ’provisional’ registration, the following apply: 


o The scheme name must meet the syntactic requirements of 
Section 3.8. 


o There must not already be an entry with the same scheme name. In 
the unfortunate case that there are multiple, different uses of 
the same scheme name, the Designated Expert can approve a request 
to modify an existing entry to note the separate use. 


o Contact information identifying the person supplying the 
registration must be included. Previously unregistered schemes 
discovered in use can be registered by third parties (even if not 
on behalf of those who created the scheme). In this case, both 
the registering party and the scheme creator SHOULD be identified. 


o If no permanent, citable specification for the scheme definition 
is included, credible reasons for not providing it SHOULD be 
given. 


o The scheme definition SHOULD include clear security considerations 
(Section 3.7) or explain why a full security analysis is not 


available (e.g., in a third-party scheme registration). 


o If the scheme definition does not meet the guidelines laid out in 
Section 3, the differences and reasons SHOULD be noted. 
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5. Guidelines for Historical URI Scheme Registration 


In some circumstances, it is appropriate to note a scheme that was 
once in use or registered but for whatever reason is no longer in 
common use or whose use is not recommended. In this case, it is 
possible for an individual to request that the URI scheme be 
registered (newly, or as an update to an existing registration) as 
‘historical’. Any scheme that is no longer in common use MAY be 
designated as /historical’; the registration SHOULD contain some 
indication as to where the scheme was previously defined or 
documented. 


6. Guidelines for Private URI Scheme Use 


Unregistered schemes can cause problems if use is not limited to a 
private environment within a single organization since the use could 
leak out beyond the closed environment. Even within a closed 
environment, other colliding uses of the same scheme name could 
occur. As such, a unique namespace MUST be used and ’provisional’ 
registration is strongly encouraged (unless the scheme name is 
constructed from a domain name), as discussed in Section 3.8. 


7. URI Scheme Registration Procedure 
7.1. General 


The IANA policy (using terms defined in [RFC5226]) for ’provisional’ 
registration was formerly Expert Review; this document changes the 
policy to First Come First Served. The policy for ’permanent’ and 
‘historical’ registration continues to be Expert Review. 


The registration procedure is intended to be very lightweight for 
noncontentious registrations. For the most part, we expect the good 
sense of submitters and reviewers, guided by these procedures, to 
achieve an acceptable and useful consensus for the community. 


In exceptional cases, where the negotiating parties cannot form a 
consensus, the final arbiter of any contested registration shall be 
the IESG. 


If standardization is anticipated, the working group or individuals 
concerned are advised to submit an early ’permanent’ registration 
request rather than waiting until the standardization process has run 
its course. IANA will pass this to the Designated Expert who may 
recommend /’provisional’ registration until the specification is 
approved as a standard. This will provide an opportunity for 
feedback while specification development and review is still active, 
and while the submitter(s) are still in a position to respond to any 
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issues that might be raised. If and when the specification is 
approved as a standard, the submitters should submit a request to 
change the registration status to ’permanent’. 


The role of the Designated Expert in the procedure for ’permanent’ 
registrations described here is to ensure that the normal open review 
process has been properly followed and to raise possible concerns 
about wider implications of proposals for the use and deployment of 
URIs. Nothing in the procedure empowers the Designated Expert to 
override properly arrived-at IETF or working group consensus. 


7.2. Registration Procedures 
Someone wishing to register a new scheme MUST: 


1. Check the IANA "Uniform Resource Identifier (URI) Schemes" 
registry to see whether there is already an entry for the desired 
name. If there is already an entry under the name, choose a 
different scheme name or update the existing scheme 
specification. 


2. Prepare a scheme registration request using the template 
specified in Section 7.4. The scheme registration request can be 
contained in an Internet-Draft, submitted alone, or as part of 
some other permanently available, stable, protocol specification. 
The scheme registration request can also be submitted in some 
other form (as part of another document or as a stand-alone 
document), but the scheme registration request will be treated as 
an “IETF Contribution" under the guidelines of [RFC5378]. 


3. If the registration request is for a ’permanent’ registration 
(or, optionally, for any other registration if desired): 


1. Review the requirements in Section 3. 


2. Send a copy of the scheme registration request or a pointer 
to the document containing the request (with specific 
reference to the section that requests the scheme 
registration) to the mailing list uri-review@ietf.org, 
requesting review. In addition, request review on other 
relevant mailing lists as appropriate. For example, general 
discussion of URI syntactical issues can be discussed on 
uri@w3.org; schemes for a network protocol can be discussed 
on a mailing list for that protocol. Allow a reasonable time 
for discussion and comments. Four weeks is reasonable for a 
‘permanent’ registration request. 
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4. 


3. Respond to review comments and make revisions to the proposed 
registration as needed to bring it into line with the 
guidelines given in this document. 


Submit the (possibly updated) scheme registration request (or 
pointer to document containing it) to IANA at iana@iana.org. 


Upon receipt of a scheme registration request, the following steps 
MUST be followed: 


Thaler, 


IANA checks the submission for completeness; if required sections 
of the scheme registration request are missing or any citations 
are not correct, IANA will reject the registration request. A 
registrant can resubmit a corrected request if desired. 


If the request is for ’provisional’ registration and no entry 
already exists in the current registry for the same name, IANA 
adds the registration to the registry under the First Come First 
Served policy. 


Otherwise, IANA enters the registration request in the IANA 
registry with the status marked as "Pending Review", and the 
remainder of this section applies. 


IANA requests Expert Review of the registration request against 
the corresponding guidelines from this document. 


The Designated Expert will evaluate the request against the 
criteria of the requested status. 


In the case of a ’permanent’ registration request, the Designated 
Expert may: 


* Accept the specification of the scheme for ’permanent’ 
registration. 


* Suggest ‘provisional’ registration instead. 


* Request IETF review and IESG approval; in the meanwhile, 
suggest ’provisional’ registration. 


* Request additional review or discussion as necessary. 


If an entry already exists for the same name, the Designated 
Expert will determine whether the request should be rejected or 
whether the existing entry should be modified to note the 
separate use. This conflict process applies regardless of the 
requested status or the status of the existing entry. 
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8. Once the Designated Expert approves registration for a given 
status, IANA updates the registration to indicate the approved 
status. If the Designated Expert instead rejects the 
registration, the "Pending Review" request is removed from the 
registry. 


Either based on an explicit request or independently initiated, the 
Designated Expert or the IESG can request the upgrade of a 
‘provisional’ registration to a ’permanent’ one. In such cases, IANA 
will update the status of the corresponding entry. Typically, this 
would only occur if the use is considered a standard (not necessarily 
an IETF standard). 


7.3. Change Control 


Registrations can be updated in the registry by the same mechanism as 
required for an initial registration. In cases where the original 
definition of the scheme is contained in an IESG-approved document, 
update of the specification also requires IESG approval. 


'Provisional’ registrations can be updated by the original registrant 
or anyone designated by the original registrant. In addition, the 
IESG can reassign responsibility for a '’provisional’ registration 
scheme or can request specific changes to a scheme registration. 

This will enable changes to be made to schemes where the original 
registrant is out of contact or unwilling or unable to make changes. 


Transition from /’/provisional’ to ’permanent’ status can be requested 
and approved in the same manner as a new ’permanent’ registration. 
Transition from ’permanent’ to '’historical’ status requires IESG 


approval. Transition from ’provisional’ to /’historical’ can be 
requested by anyone authorized to update the ’provisional’ 
registration. 


7.4. URI Scheme Registration Template 


This template describes the fields that MUST be supplied in a scheme 
registration request suitable for adding to the registry: 


Scheme name: 
See Section 3.8 for guidelines. 


Status: 
This reflects the status requested and must be one of ’Permanent’, 


"Provisional’, or ’Historical’. 


Applications/protocols that use this scheme name: 
See Section 3.5. 
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Contact: 
Person (including contact information) to contact for further 
information. 


Change controller: 
Organization or person (often the author), including contact 
information, authorized to change this. 


References: 
Include full citations for all referenced documents. Scheme 
registration requests for /’/provisional’ registration can be 
included in an Internet-Draft; when the documents expire or are 
approved for publication as an RFC, the registration will be 
updated. A scheme specification is only required for ’permanent’ 
registration. 


The previous version of this specification required the following 
additional fields in a scheme registration request. These fields are 
no longer part of the template. The answers instead belong in the 
scheme specification. 


Scheme syntax: 
See Section 3.2 for guidelines. 


Scheme semantics: 
See Section 3.3 and Section 3.4 for guidelines. 


Encoding considerations: 
See Section 3.3 and Section 3.6 for guidelines. 


Interoperability considerations: 
See Section 3.9 for guidelines. 


Security considerations: 
See Section 3.7 for guidelines. 


8. The "example" URI Scheme 
There is a need for a scheme name that can be used for examples in 
documentation without fear of conflicts with current or future actual 


schemes. The scheme "example" is hereby registered as a /permanent’ 
scheme for that purpose. 
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The "example" scheme is specified as follows: 


Scheme syntax: The entire range of allowable syntax specified in 
[RFC3986] is allowed for "example" URIs. Similarly, the entire 
range of allowable syntax specified in [RFC3987] is allowed for 
"example" IRIs. For example, <example:foo>, <example:/foo>, and 
<example://foo> are all valid. 


Scheme semantics: URIs in the "example" scheme are to be used for 
documentation purposes only. The use of "example" URIs must not be 
used as locators, identify any resources, or specify any particular 
set of operations. 


Encoding considerations: See Section 2.5 of [RFC3986] for 
guidelines. 


Interoperability considerations: None. 


Security considerations: None. 
8.1. "example" URI Scheme Registration Request 
Scheme name: example 


Status: permanent 

Applications/protocols that use this scheme name: An "example" URI 
is to be used for documentation purposes only. It MUST NOT be used 
for any protocol. 

Contact: N/A 

Change controller: IETF 

References: Section 8 of this document (RFC 7595). 

9. IANA Considerations 

Previously, the former "URL Scheme" registry was replaced by the 

"Uniform Resource Identifier (URI) Schemes" registry. The process 

was based on "Expert Review" [RFC5226] with an initial (optional) 

mailing list review. 

The updated template has an additional field for the status of the 

scheme, and the procedures for entering new name schemes have been 


augmented. Section 7 establishes the process for new scheme 
registration. 
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IANA has done the following: 
o Updated the URI Schemes registry to point to this document. 


o Combined the "Permanent URI Schemes", "Provisional URI Schemes", 
and "Historical URI Schemes" subregistries into a single common 
registry with an additional "Status" column containing the status 
(7’Permanent’, '’Provisional’, ‘’Historical’, or '’Pending Review’), 
and an additional "Notes" column that is normally empty but may 
contain notes approved by the Designated Expert. 


o Added the "example" URI scheme to the registry (see the template 
in Section 8.1 for registration). 


10. Security Considerations 


All registered values are expected to contain clear security 
considerations as discussed in Section 3.7. However, information 
concerning possible security vulnerabilities of a protocol might 
change over time. Consequently, claims as to the security properties 
of a registered scheme might change as well. As new vulnerabilities 
are discovered, information about such vulnerabilities might need to 
be attached to existing documentation, so that users are not misled 
as to the true security properties of a registered scheme. 
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